Intents for offer-discovery systems

ABSTRACT

Provided is a process of identifying an offers engine configured to provide information about offers to users, the method including: receiving, at an offers engine, a request for an offers interface website from a mobile computing device; and in response to the request, transmitting to the mobile computing device a website configured to cause a browser of the mobile computing device to perform steps, including: detecting an offers intent in the transmitted website; retrieving from memory of the mobile computing device an identifier of a native application offers interface mapped to the offers intent; and in response to retrieving the identifier of the offers engine, launching the native application, the native application being stored in memory of the mobile computing device and configured to provide an offers interface to the offers engine.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a non-provisional of, and thus claims thebenefit of, each of the following U.S. provisional patent applications,each of which is hereby incorporated by reference in its entirety forall purposes: provisional application 61/707,527, filed Sep. 28, 2012;provisional application 61/665,740, filed Jun. 28, 2012; provisionalapplication 61/658,408, filed Jun. 12, 2012; provisional application61/658,404, filed Jun. 11, 2012; and provisional application 61/658,387,filed Jun. 11, 2012.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to merchant offers and, morespecifically, to offer-discovery systems.

2. Description of the Related Art

Offer-discovery systems provide a service by which merchants informcustomers of offers, for example deals (like discounts, favorableshipping terms, or rebates) or coupons (like printable coupons forin-store use or coupon codes for use online). Typically, the systemsstore information about offers from a relatively large number ofmerchants and provide an interface by which customers can identifyoffers in which the customer is interested. Merchants have found thedeal-discovery systems to be a relatively effective form of marketing,as cost-sensitive consumers are drawn to such systems due to thesystem's relatively comprehensive listing of offers, and as a result,the number of offers listed on such systems has increased in recentyears. One consequence of this increase is that users (e.g., prospectivecustomers of the merchants) face an increasingly complex task ofidentifying relevant offers on offer-discovery systems and recallinginformation about the offer when making a purchase, potentially sometimein the future after first discovering the offer, and potentially indifferent instances of a browser window or on a different computingdevice.

Adding to the complexity faced by users is the existence of multipleoffer-discovery systems in which the user may choose to participate. Tosearch for relevant offers, users often navigate to a specificoffer-discovery system preferred by that user before searching foroffers, a task which can add several steps to the process of identifyingrelevant offers and can discourage users from searching for offers.

SUMMARY OF THE INVENTION

The following is a non-exhaustive listing of some aspects of the presenttechniques. These and other aspects are described in the followingdisclosure.

In some aspects, the present invention includes a process of operatingan offers engine configured to provide information about offers tousers, the method including: receiving, at an offers engine, a requestfor an offers interface website from a mobile computing device; and inresponse to the request, transmitting to the mobile computing device awebsite configured to cause a browser of the mobile computing device toperform steps, including: detecting an offers intent in the transmittedwebsite; retrieving from memory of the mobile computing device anidentifier of a native application offers interface mapped to the offersintent; and in response to retrieving the identifier of the offersengine, launching the native application, the native application beingstored in memory of the mobile computing device and configured toprovide an offers interface to the offers engine.

Some aspects include a process of searching for online coupons, themethod including: navigating, at a user computing device, to a webpage;ascertaining, at the computing device, that the webpage contains anoffers intent token indicating an offers intent by parsing the webpagewith a browser, the offers intent identifying a class of services bywhich online coupons are searched using an offers engine accessible overthe Internet; ascertaining, at the computing device, that an offersengine is mapped to the offers intent by obtaining from memory of theuser computing device an identifier of a mapped offers engine, themapped offers engine being previously mapped to the offers intent on thecomputing device; instantiating, on the user computing device, inresponse to ascertaining that an offers engine is mapped, an offersinterface. The offers interface being configured to communicate with theoffers engine by: receiving from the user a search query for couponsstored on the offers engine; transmitting the search query to the mappedoffers engine; receiving coupons responsive to the search query from themapped offers engine; and displaying the received coupons to the user onthe offers interface, the displayed coupons being selectable by a userand operable to cause the user device, in response to the selection, tonavigate to a merchant webpage associated with the selected coupon.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects and other aspects of the present techniqueswill be better understood when the present application is read in viewof the following figures in which like numbers indicate similar oridentical elements:

FIG. 1 illustrates an example of an offer-discovery system in accordancewith some embodiments;

FIG. 2 illustrates an example of a process by which an offers engine inthe offer-discovery system of FIG. 1, in some embodiments, obtains andprocesses data related to offers;

FIG. 3 illustrates an example of a process by which a user device in theoffer-discovery system of FIG. 1, in some embodiments, obtains andpresents to users data related to offers;

FIG. 4 illustrates an embodiment of an offer-discovery system configuredto assist users with the selection of an offer engine by mapping anoffer engine to an offers intent token embedded in offer-bearingcontent; and

FIG. 5 illustrates an embodiment of a process for facilitating couponredemption by mapping offers intents to an offers engine.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Thedrawings may not be to scale. It should be understood, however, that thedrawings and detailed description thereto are not intended to limit theinvention to the particular form disclosed, but to the contrary, theintention is to cover all modifications, equivalents, and alternativesfalling within the spirit and scope of the present invention as definedby the appended claims.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

The above-mentioned deficiencies in existing offer-discovery systems maybe mitigated by certain embodiments of an offer-discovery system 10illustrated by FIG. 1, and in particular, by variants of this systemdescribed below with reference to FIGS. 4-5, which are capable ofdetecting the presence (or selection) of a token indicating that anoffers intent (identifying offers-related services to be engaged) isrelevant to a webpage (or other content), and in response, instantiatingan offers interface with the preferred offers engine of the user,thereby relieving the user of the burden of repeatedly selecting ornavigating to their preferred offers engine.

FIG. 1 shows an embodiment of an offer-discovery system 10. Theexemplary system 10 includes an offers engine 12 that, in someembodiments, is capable of reducing the burden on users attempting toidentify offers relevant to them from among a relatively large pool ofoffers (e.g., more than 100, more than 1,000, or more than 10,000). Tothis end and others, the offers engine 12 maintains device-independentuser profiles (or portions of user profiles) by which offers interfacesmay be relatively consistently configured across multiple user deviceswith which the user interacts with the offers engine 12. Further, theoffers engine 12, in some embodiments, includes a number of featuresexpected to facilitate relatively quick identification of relevantoffers by a user, features that include cached storage of data relatedto likely relevant offers, faceted presentation of offers by which userscan select among offers within various categories, and a number of othertechniques described below for assisting with offer identification. Theoffers engine 12 is also expected to facilitate relatively low operatingcosts by, in some embodiments, automating parts of the process by whichoffer related data is acquired from sources, such as affiliate networksmerchants, administrators, or users, and automating parts of the processby which transaction data indicative of acceptance, settlement, orclearing of offers is obtained and processed.

These and other benefits are described in greater detail below, afterintroducing the components of the system 10 and describing theiroperation. It should be noted, however, that not all embodimentsnecessarily provide all of the benefits outlined herein, and someembodiments may provide all or a subset of these benefits or differentbenefits, as various engineering and cost tradeoffs are envisioned.

In the illustrated embodiment, the offers engine 12 includes a controlmodule 14, an application program interface (API) server 16, a webserver 18, an ingest module 20, an administration module 22, a datastore 24, and a cache server 23. These components, in some embodiments,communicate with one another in order to provide the functionality ofthe offers engine 12 described herein. As described in greater detailbelow, in some embodiments, the data store 24 may store data aboutoffers and users' interactions with those offers; the cache server 23may expedite access to this data by storing likely relevant data inrelatively high-speed memory, for example, in random-access memory or asolid-state drive; the web server 18 may serve webpages having offersinterfaces by which users discover relevant offers; the API server 16may serve data to various applications that process data related tooffers; the ingest module 20 may facilitate the intake of data relatedto offers from affiliate networks, users, administrators, and merchants;and the administration module 22 may facilitate curation of offerspresented by the API server 16 and the web server 18. The operation ofthese components 16, 18, 20, 22, 24, and 23 may be coordinated by thecontrol module 14, which may bidirectionally communicate with each ofthese components or direct the components to communicate with oneanother. Communication may occur by transmitting data between separatecomputing devices (e.g., via transmission control protocol/internetprotocol (TCP/IP) communication over a network), by transmitting databetween separate applications or processes on one computing device; orby passing values to and from functions, modules, or objects within anapplication or process, e.g., by reference or by value.

Among other operations, the offers engine 12 of this embodiment presentsoffers to users; receives data from users about their interaction withthe offers (for example, the user's favorite offers or offer attributes;statistics about the offers the user has identified, accepted, orotherwise provided data about; or the identity of other users with whomthe user communicates about offers and the content of thosecommunications; provided that users opt to have such data obtained);customizes the presentation of offers based on this received data; andfacilitates the processing of compensation from merchants (eitherdirectly or through affiliate networks) as a result of users accepting(or taking a specific action, like clicking or viewing, in someembodiments or use cases) offers. This interaction with users may occurvia a website viewed on a desktop computer, tablet, or a laptop of theuser. And in some cases, such interaction occurs via a mobile websiteviewed on a smart phone, tablet, or other mobile user device, or via aspecial-purpose native application executing on a smart phone, tablet,or other mobile user device. Presenting and facilitating interactionwith offers across a variety of devices is expected to make it easierfor users to identify and recall relevant offers at the time the user isinterested in those offers, which is often different from the time atwhich the user first discovers the offers. In particular, someembodiments allow users to store data indicative of offers relevant tothat user using one device, such as a desktop computer in the user'shome, and then view those offers at a later time, such as on a nativemobile application when in a retail store.

To illustrate an example of the environment in which the offers engine12 operates, the illustrated embodiment of FIG. 1 includes a number ofcomponents with which the offers engine 12 communicates: mobile userdevices 28 and 30; a desk-top user device 32; a third party offer server34; an administrator device 36; merchant servers 38, 40, and 42; andaffiliate-network servers 44 and 46. Each of these devices communicateswith the offers engine 12 via a network 48, such as the Internet or theInternet in combination with various other networks, like local areanetworks, cellular networks, or personal area networks.

The mobile user devices 28 and 30 may be smart phones, tablets, gamingdevices, or other hand-held networked computing devices having adisplay, a user input device (e.g., buttons, keys, voice recognition, ora single or multi-touch touchscreen), memory (such as a tangible,machine-readable, non-transitory memory), a network interface, aportable energy source (e.g., a battery), and a processor (a term which,as used herein, includes one or more processors) coupled to each ofthese components. The memory of the mobile user devices 28 and 30 maystore instructions that when executed by the associated processorprovide an operating system and various applications, including a webbrowser 50 or a native mobile application 52. The native application 52,in some embodiments, is operative to provide an offers interface thatcommunicates with the offers engine 12 and facilitates user interactionwith data from the offers engine 12. Similarly, the web browser 50 maybe configured to receive a website from the offers engine 12 having datarelated to deals and instructions (for example, instructions expressedin JavaScript™) that when executed by the browser (which is executed bythe processor) cause the mobile user device to communicate with theoffers engine 12 and facilitate user interaction with data from theoffers engine 12. The native application 52, and the web browser 50 uponrendering a webpage from the offers engine 12, may generally be referredto as client applications of the offers engine 12, which in someembodiments may be referred to as a server. Embodiments, however, arenot limited to client/server architectures, and the offers engine 12, asillustrated, may include a variety of components other than thosefunctioning primarily as a server.

The desk-top user device 32 may also include a web browser 54 thatserves the same or similar role as the web browser 50 in the mobile userdevice 30. In addition, the desk-top user device 32 may include amonitor; a keyboard; a mouse; memory; a processor; and a tangible,non-transitory, machine-readable memory storing instructions that whenexecuted by the processor provide an operating system and the webbrowser.

Third-party offer server 34 may be configured to embed data from theoffers engine 12 in websites or other services provided by thethird-party offer server 34. For example, third-party offer server 34may be a server of a social networking service upon which users postcomments or statistics about offers with which the user has interacted,or the users may use the offer server 34 to recommend offers to othersor identify offers to avoid. In another example, third-party offerserver 34 may include various services for publishing content to theWeb, such as blogs, tweets, likes, dislikes, ratings, and the like. Inanother example, third-party offer server 34 provides services by whichthird-parties curate offers hosted by the offers engine 12.

Merchant servers 38, 40, and 42 host websites or other user accessiblecontent interfaces by which users can accept offers hosted by the offersengine 12. In some embodiments, and in some use cases, the merchantservers 38, 40, and 42 host retail websites that present a plurality ofitems for sale by the merchant, a subset of which may include items towhich offers apply, thereby generally making the item for sale moredesirable to cost-sensitive consumers than under the terms presented bythe merchant in the absence of the offer. For example, the offers mayinclude free or discounted shipping, a discounted price, a bulkdiscount, a rebate, a referral award, or a coupon, such as a couponacceptable by presenting a coupon code during checkout on the merchantwebsite, or a printable or displayable coupon (e.g., on the screen of amobile device) for in-store use, the printable or otherwise displayablecoupon having, in some cases, a machine readable code (e.g., a bar codeor QR code for display and scanning, or a code passed via near-fieldcommunication or Bluetooth™). In some embodiments, the merchant websiteincludes a checkout webpage having an interface for the user to enterpayment information and a coupon code, and the merchant website (eitherwith logic on the client side or the server-side) may validate thecoupon code entered by the user and, upon determining that the couponcode is valid, adjust the terms presented to the user for acceptance inaccordance with the offer.

Some merchants may limit the number of uses of a given coupon, limit theduration over which the coupon is valid, or apply other conditions touse of the coupon, each of which may add to the burden faced by usersseeking to find valid coupons applicable to an item the user wishes topurchase. As noted above, some embodiments of the offers engine 12 areexpected to mitigate this burden.

Further, in some embodiments, the merchant servers 38, 40, and 42provide data about offers to the offers engine 12 or (i.e., and/or, asused herein, unless otherwise indicated) data about transactionsinvolving offers. In use cases in which the operator of the offersengine 12 has a direct affiliate-marketing relationship with one of themerchants of the merchant servers 38, 40, or 42, the transaction datamay provide the basis for payments by the merchant directly to theoperator of the offers engine 12. For example, payments may be based ona percentage of transactions to which offers were applied, a number ofsales to which offers were applied, or a number of users who viewed orselected or otherwise interacted with an offer by the merchant.

Affiliate-network servers 44 and 46, in some embodiments and some usecases, are engaged when the entity operating the offers engine 12 doesnot have a direct affiliate-marketing relationship with the merchantmaking a given offer. In many affiliate marketing programs, merchantscompensate outside entities, such as third-party publishers, for certainactivities related to sales by that merchant and spurred by the outsideentity. For example, in some affiliate marketing programs, merchantscompensate an affiliate, such as the entity operating the offers engine12, in cases in which it can be shown that the affiliate provided agiven coupon code to a given user who then used that coupon code in atransaction with the merchant. Demonstrating this connection to themerchant is one of the functions of the affiliate-networks.

Affiliate-networks are used, in some use cases, because many couponcodes are not affiliate specific and are shared across multipleaffiliates, as the merchant often desires the widest distribution of arelatively easily remembered coupon code. Accordingly, in some usecases, the merchant, affiliate network, and affiliate cooperate to useclient-side storage to indicate the identity of the affiliate thatprovided a given coupon code to a user. To this end, in someembodiments, when a webpage offers interface is presented by the offersengine 12 in the web browsers 50 or 54, that webpage is configured bythe offers engine 12 to include instructions to engage the affiliatenetwork server 44 or 46 when a user selects an offer, for example, byclicking on, touching, or otherwise registering a selection of an offer.The website provided by the offers engine 12 responds to such aselection by, in some embodiments, transmitting a request to theappropriate affiliate-network server 44 or 46 (as identified by, forexample, an associated uniform resource locator (URL) in the webpage)for a webpage or portion of a webpage (e.g., browser-executablecontent). The request to the affiliate-network server may include (e.g.,as parameters of the URL) an identifier of the affiliate, the offer, andthe merchant, and the returned content from the affiliate-network servermay include instructions for the web browser 50 or 54 to store in memory(e.g., in a cookie, or other form of browser-accessible memory, such asa SQLite database or in a localStorage object via a localStorage.setItemcommand) an identifier of the affiliate that provided the offer that wasselected.

The webpage from the offers engine 12 (or the content returned by theaffiliate network server 44 or 46) may further include browserinstructions to navigate to the website served by the merchant server38, 40, or 42 of the merchant associated with the offer selected by theuser, and in some cases to the webpage of the item or service associatedwith the offer selected by the user. When a user applies the offer, forexample by purchasing the item or service or purchasing the item orservice with the coupon code, the merchant server 38, 40, or 42 maytransmit to the user device upon which the item was purchased browserinstructions to request content from the affiliate network server 44 or46, and this requested content may retrieve from the client-side memorythe identifier of the affiliate, such as the operator of the offersengine 12, who provided the information about the offer to the user. Theaffiliate network may then report to the merchant the identity of theaffiliate who should be credited with the transaction, and the merchantmay compensate the affiliate (or the affiliate network may bill themerchant, and the affiliate network may compensate the affiliate), suchas the operator of the offers engine 12. Thus, the affiliate network inthis example acts as an intermediary, potentially avoiding the need forcross-domain access to browser memory on the client device, a featurewhich is generally not supported by web browsers for security reasons.(Some embodiments may, however, store in client-side browser-accessiblememory an identifier of the affiliate upon user selection of the offer,with this value designated as being accessible via the merchant'sdomain, and provide the value to the merchant upon a merchant requestfollowing acceptance of the offer, without passing the identifierthrough an affiliate network, using a browser plug-in for providingcross-domain access to browser memory or a browser otherwise configuredto provide such access.)

A similar mechanism may be used by the native application 52 forobtaining compensation from merchants. In some embodiments, the nativeapplication 52 includes or is capable of instantiating a web browser,like the web browser 50, in response to a user selecting an offerpresented by the native application 52. The web browser instantiated bythe native application 52 may be initialized by submitting theabove-mentioned request for content to the affiliate-network server 44or 46, thereby storing an identifier of the affiliate (i.e., the entityoperating the offers engine 12 in this example) in client-side storage(e.g., in a cookie, localStorage object, or a database) of the mobileuser device 28, and thereby navigating that browser to the merchantwebsite. In other use cases, the operator of the offers engine 12 has adirect relationship with the merchant issuing the offer, and theselection of an offer within the native application 52 or the desktop ormobile website of the offers engine 12 (generally referred to herein asexamples of an offer interface) may cause the user device to request awebsite from the associated merchant with an identifier of the affiliateincluded in the request, for example as a parameter of a URL transmittedin a GET request to the merchant server 38, 40, or 42 for the merchant'swebsite.

Administrator device 36 may be a special-purpose application or aweb-based application operable to administer operation of the offersengine 12, e.g., during use by employees or agents of the entityoperating the offers engine 12. In some embodiments, the administrationmodule 22 may communicate with the administrator device 36 to present anadministration interface at the administrator device 36 by which anadministrator may configure offers interfaces presented to users by theoffers engine 12. In some embodiments, the administrator may enteroffers into the offers engine 12; delete offers from the offers engine12; identify offers for prominent placement within the offers interface(e.g., for initial presentation prior to user interaction); moderatecomments on offers; view statistics on offers, merchants, or users; addcontent to enhance the presentation of offers; or categorize offers.

Thus, the offers engine 12, in some embodiments, operates in theillustrated environment by communicating with a number of differentdevices and transmitting instructions to various devices to communicatewith one another. The number of illustrated merchant servers, affiliatenetwork servers, third-party servers, user devices, and administratordevices is selected for explanatory purposes only, and embodiments arenot limited to the specific number of any such devices illustrated byFIG. 1.

The offers engine 12 of some embodiments includes a number of componentsintroduced above that facilitate the discovery of offers by users. Forexample, the illustrated API server 16 may be configured to communicatedata about offers via an offers protocol, such as arepresentational-state-transfer (REST)-based API protocol over hypertexttransfer protocol (HTTP). Examples of services that may be exposed bythe API server 18 include requests to modify, add, or retrieve portionsor all of user profiles, offers, or comments about offers. API requestsmay identify which data is to be modified, added, or retrieved byspecifying criteria for identifying records, such as queries forretrieving or processing information about particular categories ofoffers, offers from particular merchants, or data about particularusers. In some embodiments, the API server 16 communicates with thenative application 52 of the mobile user device 28 or the third-partyoffer server 34.

The illustrated web server 18 may be configured to receive requests foroffers interfaces encoded in a webpage (e.g. a collection of resourcesto be rendered by the browser and associated plug-ins, includingexecution of scripts, such as JavaScript™, invoked by the webpage). Insome embodiments, the offers interface may include inputs by which theuser may request additional data, such as clickable or touchable displayregions or display regions for text input. Such inputs may prompt thebrowser to request additional data from the web server 18 or transmitdata to the web server 18, and the web server 18 may respond to suchrequests by obtaining the requested data and returning it to the userdevice or acting upon the transmitted data (e.g., storing posted data orexecuting posted commands). In some embodiments, the requests are for anew webpage or for data upon which client-side scripts will base changesin the webpage, such as XMLHttpRequest requests for data in a serializedformat, e.g. JavaScript™ object notation (JSON) or extensible markuplanguage (XML). The web server 18 may communicate with web browsers,such as the web browser 50 or 54 executed by user devices 30 or 32. Insome embodiments, the webpage is modified by the web server 18 based onthe type of user device, e.g., with a mobile webpage having fewer andsmaller images and a narrower width being presented to the mobile userdevice 30, and a larger, more content rich webpage being presented tothe desk-top user device 32. An identifier of the type of user device,either mobile or non-mobile, for example, may be encoded in the requestfor the webpage by the web browser (e.g., as a user agent type in anHTTP header associated with a GET request), and the web server 18 mayselect the appropriate offers interface based on this embeddedidentifier, thereby providing an offers interface appropriatelyconfigured for the specific user device in use.

The illustrated ingest module 20 may be configured to receive data aboutnew offers (e.g., offers that are potentially not presently stored inthe data store 24), such as data feeds from the affiliate networkservers 44 and 46, identifications of offers from user devices 28, 30,or 32, offers identified by third-party offer server 34, offersidentified by merchant servers 38, 40, or 42, or offers entered by anadministrator via the administrator device 36. In some embodiments, theingest module 20 may respond to receipt of a record identifying apotentially new offer by querying the data store 24 to determine whetherthe offer is presently stored. Upon determining that the offer is notpresently stored by the data store 24, the ingest module 20 may transmita request to the data store 24 to store the record. In some cases, thedata about new offers may be an affiliate data-feed from an affiliatenetwork containing a plurality of offer records (e.g., more than 100),each record identifying offer terms, a merchant, a URL of the merchantassociated with the offer, a product description, and an offeridentifier. The ingest module 22 may periodically query such data-feedsfrom the affiliate-network servers 44 or 46, parse the data-feeds, anditerate through (or map each entry to one of a plurality of processesoperating in parallel) the records in the data-feeds. Bulk, automatedprocessing of such data-feeds is expected to lower operating costs ofthe offers engine 12.

The administration module 22 may provide an interface by which anadministrator operating the administrator device 36 curates andcontextualizes offers. For example, the administration module 22 mayreceive instructions from administrator that identify offers to bepresented in the offer interface prior to user interaction with theoffer interface, or offers to be presented in this initialized offersinterface for certain categories of users, such as users having certainattributes within their user profile. Further, in some embodiments, theadministration module 22 may receive data descriptive of offers from theadministrator, such as URLs of images relevant to the offer,categorizations of the offer, normalized data about the offer, and thelike.

The illustrated data store 24, in some embodiments, stores data aboutoffers and user interactions with those offers. The data store 24 mayinclude various types of data stores, including relational ornon-relational databases, document collections, hierarchical key-valuepairs, or memory images, for example. In this embodiment, the data store24 includes a user data store 56, a session data store 58, an offersdata store 60, and an analytics data store 62. These data stores 56, 58,60, and 62 may be stored in a single database, document, or the like, ormay be stored in separate data structures.

In this embodiment, the illustrated user data store 56 includes aplurality of records, each record being a user profile and having a useridentifier, a list of offers (e.g., identifiers of offers) identified bythe user as favorites, a list of categories of offers identified by theuser as favorites, a list of merchants identified by the user asfavorites, account information for interfacing with other services towhich the user subscribes (e.g., a plurality of access records, eachrecord including an identifier of a service, a URL of the service, auser identifier for the service, an OAuth access token credential issuedby the service at the user's request, and an expiration time of thecredential), a user password for the offers engine 12, a location of theuser device or the user (e.g., a zip code of the user), and a gender ofthe user. In some embodiments, each user profile includes a list ofother users identified by the user of the user profile as being peoplein whose commentary on, or curation of, offers the user is interested,thereby forming an offers-interest graph. In some embodiments, usershave control of their data, including what is stored and who can viewthe data, and can choose to opt-in to the collection and storage of suchuser data to improve their experience with the offers engine 12.

In this embodiment, the session data store 58 stores a plurality ofsession records, each record including information about a session agiven user is having or has had with the offers engine 12. The sessionrecords may specify a session identifier, a user identifier, and statedata about the session, including which requests have been received fromthe user and what data has been transmitted to the user. Session recordsmay also indicate the IP address of the user device, timestamps ofexchanges with the user device, and a location of the user device (e.g.,retail store or aisle in a retail store in which the user device islocated).

The illustrated offers data store 60, in some embodiments, includes aplurality of offer records, each offer record may identify a merchant,offers by that merchant, and attributes of the relationship with themerchant, e.g., whether there is a direct relationship with the merchantby which the merchant directly compensates the operator of the offersengine 12 or whether the merchant compensates the operator of the offersengine 12 via an affiliate network and which affiliate network. Theoffers by each merchant may be stored in a plurality of merchant-offerrecords, each merchant-offer record may specify applicable terms andconditions of the offer, e.g., whether the offer is a discount, includesfree or discounted shipping, requires purchase of a certain number ofitems, is a rebate, or is a coupon (which is not to suggest that thesedesignations are mutually exclusive). In records in which the offer is acoupon, the record may further indicate whether the coupon is forin-store use (e.g. whether the coupon is associated with a printableimage for presentation at a point-of-sale terminal, a mobiledevice-displayable image, or other mediums) or whether the coupon is foronline use and has a coupon code, in which case the coupon code is alsopart of the merchant-offer record. The merchant-offer records may alsoinclude an expiration date of the offer, comments on the offer, rankingsof the offer by users, a time at which the offer was first issued orentered into the offers engine 12, and values (e.g., binary values)indicating whether users found the offer to be effective, with eachvalue or ranking being associated with a timestamp, in some embodiments.The values and rankings may be used to calculate statistics indicativeof the desirability of the offer and likely success of accepting theoffer. The timestamps associated with the values, rankings, and time ofissuance or entry into the offers engine 12 may also be used to weightrankings of the offer, with older values being assigned less weight thannewer values and older offers being ranked lower than newer offers, allother things being equal, as many offers expire or have a limited numberof uses.

The illustrated analytics data store 62 may store a plurality of recordsabout historical interactions with the offers engine 12, such asaggregate statistics about the performance of various offers. In someembodiments, the analytics data store 62 stores a plurality oftransaction records, each transaction record identifying an offer thatwas accepted by a user at a merchant, the merchant, the time ofpresentation of the offer to the user, and an indicator of whether themerchant has compensated the entity operating the offers engine 12 forpresentation of the offer to the user. Storing and auditing thesetransaction records is expected to facilitate relatively accuratecollection of payments owed by merchants and identification of futureoffers likely to lead to a relatively high rates of compensation forprominent presentation based on past performance of offers havingsimilar attributes.

The cache server 23 stores a subset of the data in the data store 24that is among the more likely data to be accessed in the near future. Tofacilitate relatively fast access, the cache server 23 may store cacheddata in relatively high speed memory, such as random access memory or asolid-state drive. The cached data may include offers entered into theoffers engine 12 within a threshold period of time, such as offers thatare newer than one day. In another example, the cache data may includeoffers that are accessed with greater than a threshold frequency, suchas offers that are accessed more than once a day, or offers accessedwithin the threshold, such as offers accessed within the previous day.Caching such offer data is expected to facilitate faster access to offerdata than systems that do not cache offer data.

The illustrated control module 14, in some embodiments, controls theoperation of the other components of the offers engine 12, receivingrequests for data or requests to add or modify data from the API server16, the web server 18, the ingest module 20, and the administrationmodule 22, and instructing the data store 24 to modify, retrieve, or adddata in accordance with the request. The control module 14 may furtherinstruct the cache server 23 to modify data mirrored in the cache server23. In some embodiments, the cache server 23 may be updated hourly, andinconsistent data may potentially be maintained in the cache server 23in order to conserve computing resources.

The illustrated components of the offers engine 12 are depicted asdiscrete functional blocks, but embodiments are not limited to systemsin which the functionality described herein is organized as illustratedby FIG. 1. The functionality provided by each of the components of theoffers engine 12 may be provided by software or hardware modules thatare differently organized than is presently depicted, for example suchsoftware or hardware may be intermingled, broken up, distributed (e.g.within a data center or geographically), or otherwise differentlyorganized.

FIG. 2 is a flowchart of a process 64 for acquiring data related tooffers within some embodiments of the offer engine 12 discussed above.In this embodiment, the process 64 begins with receiving offer datadescribing a plurality of offers from affiliate networks, merchants, andusers, as illustrated by block 66. This step may be performed by theabove-mentioned ingest module 20. As noted above, the received offerdata may be received from one or all of these sources. The receivedoffer data may be received via an offer interface by which usersassociated with these sources enter data about offers, or the receivedoffer data may be received in a predefined format, such as a serializeddata format, in an automatic data feed pushed or pulled periodically orin response to the availability of new data from affiliate networks ormerchants. Receiving the offer data may include determining whether theoffer data is redundant to offer data already received and normalizingthe offer data.

The process 64, in some embodiments, includes normalizing and enrichingthe offer data, as indicated by block 67. Normalizing may includenormalizing field names of the data and normalizing the way in whichdates are expressed, for example. Enriching may include associatingimages with the offers for presentation with the offers and addingmetadata to the offers to assist users searching for offers.

Next, in the present embodiment, the received offer data is stored in anoffer data store, as indicated by block 68. Storing the offer data inthe offer data store may include identifying a merchant to which theoffer pertains and storing the offer in a merchant-offer recordassociated with that merchant. Further, some embodiments may includeinserting the offer in order in a sorted list of offers for relativelyfast retrieval of offers using a binary search algorithm or othertechniques to facilitate relatively quick access to data that has beenpreprocessed (e.g., using a prefix trie). In some embodiments, storingthe received offer may further include updating hash tables by which theoffer may be retrieved according to various parameters, each hash tablebeing associated with one parameter and including a hash key valuecalculated based on the parameter and paired with an address of theoffer. Such hash tables are expected to facilitate relatively fastaccess to a given offer as the need to iterate through potentially alloffers meeting certain criteria may be potentially avoided.

In some embodiments, the process 64 further includes receiving a requestfrom a user device for offers, as indicated by block 70. The request mayspecify criteria for identifying offers, such as categories of offers,search terms for offers, or requests for offers designated as favorites.

Next, the present embodiment includes identifying offers in the offerdata store responsive to the user request, as indicated by block 72.Identifying offers in the offer data store may be performed by theabove-mentioned control module 14 (FIG. 1) by constructing a query tothe offer data store 60 based on a request received from the web server18 or the API server 16. The query may be transmitted to the offer datastore 60, or to the cache server 26, each of which may return responsiverecords.

Next, the identified offers are transmitted to the user device, asindicated by block 74. Transmitting the identified offers may includetransmitting the identified offers in an offer interface, such as awebpage, or an API transmission to a native mobile application, forexample by the web server 18, or the API server 16 of FIG. 1,respectively.

The device receiving the identified offers may, in response, perform aprocess described below with reference to FIG. 3 by which additionaloffers are requested or an offer is selected and a purchase is executed.This process of FIG. 3 and steps 70 through 74 of FIG. 2 may be repeatednumerous times, in some use cases, before advancing to the next steps.Further, the steps 66 through 68 may be repeated numerous timesindependently of (e.g., concurrent with) the performance of steps 70through 74 of FIG. 2 (which is not to suggest that other steps describedherein may not also be executed independently). That is, the process 64may undergo step 60 and 68, for example, 50 times within a given time,while performing steps 70 through 74 500 times within that given time,and performing the remaining steps of process 64 a single time.

In some embodiments, a user device undergoing the process of FIG. 3 mayindicate to an offers engine that the user has selected an offer (e.g.,by clicking on or touching a selectable element in an offers interfaceassociated with the offer). In response, the offers engine may directthe user device to an affiliate-network server or a merchant serverassociated with the offer, as illustrated by block 75.

Next, this embodiment of the process 64 includes receiving frommerchants or affiliate networks transaction data identifying offersaccepted via the user device, as illustrated by block 76. Thetransaction data may be pulled from these sources, for example, by theingest module 20 of FIG. 1, periodically, or in response to somethreshold number of transactions having occurred.

Next, in this embodiment, the receipt transaction data may be stored inan analytics data store, as indicated by block 78. In some embodiments,this data may be stored in the analytics data store 62 of FIG. 1.Storing the transaction data is expected to facilitate theidentification of attributes of relatively profitable offers, as thetransaction data indicates which offers historically yielded compensabletransactions. Further, storing the transaction data is expected tofacilitate relatively accurate auditing of payments from merchants oraffiliate networks.

FIG. 3 is a flowchart of an embodiment of a process 80 that provides anexample of an offer interface at a user device. The process 80 may beperformed by the above-mentioned native application 52 or web browser 50or 54 in cooperation with the offers engine 12.

Some embodiments of process 80 begin with receiving, at a user device,instructions that cause the user device to display an offers interface,as indicated by block 82. The received instructions may be in the formof a downloaded native application, such as one downloaded from anapplication store hosted by a provider of mobile devices, or thereceived instructions may be in the form of a website received from theoffers engine 12 and rendered in a browser of the user device.

In some embodiments, the process 80 further includes receiving, at theuser device, a plurality of offers, as indicated by block 84, anddisplaying, at the user device, the offers in the offer interface, asindicated by block 86. The offers may be received at approximately thesame time the instructions of step 82 are received, for example alongwith a webpage, or the offers may be received at a later date, forexample during a session subsequent to downloading the nativeapplication.

The offers interface may include inputs by which the user may search,filter, or otherwise browse offers having various attributes. Some ofthese interfaces are described below with reference to steps performedto determine whether the user has engaged these inputs. In someembodiments, determining whether the user has engaged these inputs maybe performed by an event handler executed by the user device, the eventhandler causing the user device to perform the corresponding,below-described requests to the offers engine 12 based on the type ofevent, e.g., whether the user touched, clicked, or otherwise selected aparticular button on the offers interface.

Illustrated process 80 includes determining whether the user issearching for offers, as indicated by block 88. With the offersinterface, the user may express their intention to search for offers byentering search terms in a text entry box and selecting a button torequest a search in accordance with the entered search term. Uponselecting this button, the user device may transmit a request for offerssatisfying the entered search criteria, as indicated by block 90. Thetransmitted request may be in the form of a GET request or an API callto the web server 18 or the API server 16 of the offers engine 12 ofFIG. 1.

In some embodiments, the process 80 further includes determining whetherthe user requests offers within a collection of offers, as indicated byblock 92. The offers interface may include selectable inputs thatidentify the collections, such as clickable collection names, collectionselection buttons, or collection selection tabs. Examples of collectionsinclude categories of goods or services, such as sporting goods,house-wares, groceries, and the like; collections of modes of couponredemption, such as in-store coupon redemption and online couponredemption; collections based on offer statistics, such as newestoffers, most popular offers, highest ranked offers; collections ofoffers designated by a user or other users; or collections based thevalue conferred by the offer, such as discounts, free shipping, rebates,and referral fees. Upon determining that the user has requested offerswithin a collection, the user device may transmit a request for offerswithin the collection to the offers engine 12, as indicated by block 94,which may return data responsive to the request.

In some embodiments, the process 80 includes determining whether theuser requests offers previously designated by the user, as indicated byblock 96. In some embodiments, the offers interface may include an inputby which a user can designate an offer, such as designating offers asbeing a user favorite, designating offers as being ranked in aparticular fashion, or designating offers as likely being of interest tosome other user, such as users adjacent one another in a social graph.The offers interface may include an input for a user to makedesignations, such as a user selectable input labeled “add to myfavorites” or “add to my wallet,” and an input for a user to requestoffers having a designation, such as a user selectable input labeled“view my favorites” or “view my wallet.” Upon determining that the usermade such a request, the process 80 includes transmitting a request forthe offers previously designated by the user, as indicated by block 88.The transmission may be made to the offers engine 12, to the API server16 or the web server 18, as described above with reference to FIG. 1,and may include an identification of the designation and the user.

The process 80, in some embodiments, further includes determiningwhether the user requests offers previously designated by another user,as indicated by block 100. The offers interface, in some embodiments,may include an input by which a user makes such a request, such as auser selectable input labeled “offers recommended by my friends.” Upondetermining that the user has made such a request, the process 80transmits a request for offers previously designated by the other user(or users), as indicated by block 102. Again, the transmission may be tothe offers engine 12 of FIG. 1, which may store or otherwise have accessto offers designated by other users and a social graph of the user bywhich responsive offers are identified. Further, the offers interfacemay include an input by which the user may view identifiers of otherusers and add the other users to an offer-interest graph of the user.This offer interest graph may be referenced by the offers engine 12 toidentify offers in response to the request of step 102.

The process 80 further includes, in some embodiments, receiving, at theuser device, one or more offers responsive to the request, as indicatedby block 104, and displaying the responsive offers on the offersinterface, as indicated by block 106.

In some embodiments and some use cases, a selection from the user isreceived via the offers interface, thereby identifying an offer amongthe displayed offers, as indicated by block 108. In some embodiments,each of the offers may be displayed with an associated input by whichthe user selects the offer, such as a touchable or clickable button,region, or text. The selection, in some embodiments, may cause theoffers interface to request additional data from the offers engine, suchas instructions from the offers engine to navigate to anaffiliate-network server associated with the offer or to navigate to amerchant server associated with the offer. In other embodiments, suchinstructions may be present within the offers interface, e.g., in theform of URLs linking to these servers.

The process 80 further includes determining whether the selected offeris compensable through an affiliate network, as indicated by block 110.This determination may be made by the offers engine 12, in someembodiments, for each of the offers being displayed prior totransmission of the offers to the user device. For example, each offermay be associated with a designation indicating whether the offer iscompensable in this fashion, and the designation may be transmittedalong with the offer, for instance, by associating the offer with HTMLor JavaScript™ that so designate the offer, or by including a fieldincluding the designation in a response to an API call for each offer.The user device, in some embodiments, may take different actionsdepending on the designation associated with the selected offer.

Upon determining that the selected offer is not compensable through anaffiliate network, the process 80 of this embodiment includesdetermining whether the selected offer is compensable directly from themerchant associated with the offer, as indicated by block 112. Again,the determination of block 112 may be performed, in some embodiments, bythe offers engine 12 for each of the offers being displayed prior totransmission of the displayed offers, and each displayed offer may beassociated with a designation based on the results of the determination,such as different HTML or JavaScript™ or a different field value in anAPI response. The user device may take different actions depending onthis designation.

Upon determining that the selected offer is not compensable directlyfrom the merchant, the process 80 may proceed to block 118 describedbelow. Upon determining that the selected offer is compensable, theprocess 80, in this embodiment, may proceed to request the website ofthe merchant issuing the selected offer with a request that identifiesthe affiliate from whom the selected offer was obtained, as indicated byblock 114. The request may be in the form of a URL having as a parameteran identifier of the entity operating the offer engine 12, therebyindicating to the merchant that the affiliate should be compensated inaccordance with an arrangement between the merchant and the affiliate.Upon performance of step 114, the process 80 of the present embodimentproceeds to step 120 described below.

As indicated by block 110, upon determining that the selected offer iscompensable through an affiliate network, the process 80 proceeds totransmit a request to the affiliate-network server for instructions tostore data identifying an affiliate from whom the selected offer wasobtained, as indicated by block 116. This request may be a request forcontent from the affiliate-network server that is not displayed to theuser, or is not displayed to the user for an appreciable amount of time(e.g., less than 500 ms), and the request may include an identifier ofthe affiliate, the merchant, and the offer. The requested content maycause the user device to store in persistent memory of the browser ofthe user device (e.g., memory that lasts between sessions, such as acookie or a database of the browser) an identifier of the affiliateoperating the offers engine 12. This value may be retrieved later by theaffiliate-network at the instruction of the merchant upon the useraccepting the offer, for example by the user using a coupon codeassociated with the offer at the merchant, thereby allowing the merchant(or the affiliate network) to identify the appropriate party tocompensate for the sale.

Upon transmitting the request the affiliate network server, the process80 further includes requesting the website of the merchant issuing theselected offer, as indicated by block 118, and transmitting acceptanceof the offer to the merchant via the merchant's website, as indicated byblock 120. Accepting the offer, as noted above, may cause the merchantto compensate the affiliate operating the offers engine 12.

The process 80 of FIG. 3 is expected to facilitate relatively fastaccess to offers that are likely to be relevant to a user, as each ofthe determinations of step 88, 92, 96, and 100 provide different pathsby which the user can specify offers in which the user is likely to beinterested. Further, the determinations of step 110 and 112 provide dualmechanisms by which the operator of the offers engine 12 can becompensated, thereby potentially increasing revenue.

FIG. 4 illustrates an offer-discovery system 122 that is configured toassist users with the selection of an offers engine by mapping all orpart of an offers engine (which may include mapping an interface for thesame) to an offers intent token, which may be embedded in websites,programs, applications, or other content relevant to offers. Forexample, an offers intent token may be embedded in a mobile website ofan offers engine, a checkout website of a merchant, an application orprogram of a server at a point-of-sale, or even an application onanother user's device that is capable of transmitting content relevantto offers. As explained in greater detail below, upon detecting thepresence of (or selection of) the offers intent token, user devices mayreference the mapping to determine which offers engine a user hasselected for handling intents related to offers, and instantiate anoffers interface of the selected offers engine, thereby relieving theuser of the burden of navigating to, or launching, the offers interfaceof their preferred offers engine. As explained below, the mapping ofintents to offers engines may be performed by an operating system of theuser computing device, e.g., in memory of a browser or in registrysettings, depending on the embodiment. Various types of offers engineintents may be used, e.g., some may map to an offers engine generally(e.g., either in a web browser or a native application) and some may mapspecifically to a native application for interfacing with an offersengine, as described below. And the offers intent may be expressed withvarious techniques, including as HTML tags, or as a URI that is mappedto a native application during installation of the native application.

Mapping all or part of an offers engine to an offers intent, such as aURI, token, or other string, may include recording in memory aone-to-one correlation between the offers intent and a selected offersengine to be engaged upon processing of the offers intent, e.g.,programmatically opening a URI. In such mappings, in some cases, one andonly one offers engine corresponds to a given intent, but notnecessarily vice versa: in some cases, the mapping may include aone-to-many correlation, associating multiple types of intents to asingle offers engine. The mapping may be stored in memory of a userdevice, e.g., in a registry of the user device or preferences settingsof the user device, or such mappings may be stored remotely, e.g., on aserver that is accessed with reference to a user account to determinethe mapping across a plurality of user devices. This mapping may bestored in memory designated in code that effectuates intents, such thatthe mapping may be referenced when the intent is processed.

The offer-discovery system 122 may include all or a subset of thecomponents of the offer-discovery system 10 of FIG. 1. In thisembodiment, the merchant server 38, offers engine 12, and network 48 areillustrated. The system 122 also includes a user computing device 124operable to detect intent tokens (or selection of the same by a user)signaling an offers intent, ascertain which offers engine is mapped tothe intent token (or solicit such a mapping from the user), and inresponse, instantiate an instance of an offers interface of the mappedoffers engine, for example, by launching a native application forinterfacing with the mapped offers engine, requesting a website in abrowser from the mapped offers engine, or making an API call to themapped offers engine. As illustrated by FIG. 4, the exemplary system 122includes multiple offers engines 12, 126, and 128, each of which mayinclude some or all of the features of the offer engine 12 describedabove, and one or more of which may be mapped to handle offers intentsin webpages or other content.

In some embodiments, the user computing device 124 includes a browser130 with which the user may navigate to various websites availablethrough the network 48, including a website of the merchant server 38.As explained in greater detail below, the browser 130 may be configuredto render webpages of the merchant received from the merchant server 38,and in the process of rendering these webpages, detect the presence ofan offers intent token, such as an intent HTML tag embedded in thewebpage. In general, intents are asynchronous messages that requestfunctionality, such as the functionality provided by an offers engine,though some embodiments may handle intents synchronously. The requestedfunctionality, when processed asynchronously, may be performed while theprocess that requested the functionality operates concurrently. Requestsfor such functionality may be included in websites or other content inwhich such functionality is likely to be relevant to a user, for examplewithin a checkout page of the merchant. In some embodiments, thecheckout page includes an intent token selectable by the user to requestfunctionality of an offers engine, and in particular, the functionalityof a specific offers engine previously mapped for handling offersintents. In some embodiments, the merchant webpage may include auser-selectable icon, for example, labeled “check for coupons,” and thatuser selectable icon may be associated with an offers intent by whichthe user's preferred offers engine may be engaged.

In another example of content that may include an offers intent, awebsite (which includes embedded web content, such as an i-frame) hostedby the offers engines 12, 126, or 128 may include an offers intent tag.The offers intent tag may be mapped to a native application forinterfacing with the offers engines 12, 126, or 128, and upon detectingthe presence of the offers intent tag, the user may be presented by thebrowser with the option of interacting with the user's preferred offersengine 12, 126, or 128 via the native application, rather than thewebsite interface of the offers engine 12, 126, or 128. Accepting theoption may cause the native application to launch, and declining theoption may allow the user to continue using the webpage. In certain usecases, native applications are more responsive than websites, as thenative applications may use hardware acceleration of graphics to providea more aesthetically pleasing and intuitive interface. The intents tag,in some embodiments, may prompt the browser to present the user with theoption of installing the native application in cases in which the nativeapplication is not presently installed, or the intents tag may beignored in some embodiments in which no mapping has occurred.

The offers intent is stored, in some embodiments, in an offers enginemapping 132, which may map an offers intent to a particular offersengine 12, 126, or 128 (e.g., a native application or website forpresenting an interface to such an offers engine). The offer enginemapping 132 may be stored, for example, in memory of the browser, or inmemory accessible to the operating system of the user computing device124 generally. For instance, the mapping may be stored in a registry ofthe user computing device 124. The mapping may include a key-value pairin which the key identifies the type of intents tag, in this case anoffers intent, and the value identifies an offers engine to handle theintent. The browser 130 may request the value of the offers enginemapping 132 in response to a user requesting to view an offers interfacefrom the merchant website. The browser 130 may also be configured toinstantiate an offers interface, for example, by launching a nativeapplication or requesting a webpage, for the offers engine identified bythe offers engine mapping 132.

The offers interface instantiated as a result of the user selecting theintent may be initialized based on data conveyed with the request toinstantiate the offers interface. For example, the request may includecontext data identifying to the offers engine 12 a merchant of themerchant website or an item for sale by the merchant in the user'sshopping cart, and the offers engine 12 may initialize the offersinterface to include content relevant to this context data, for example,including offers by the merchant, offers by the merchant applying to anitem in the user shopping cart on the merchant's website, or offers bymerchants selling similar items (for example, in the same category) orthe same item. Further, the request for the offers interface may specifya type of action, such as a particular initial state of the offersinterface, like an offers interface including search results, an offersinterface for sharing the offer with others adjacent the user in asocial graph, or an offers interface for rating or commenting on theoffer. The offers engine 12 may initialize the offers interface based onthis type of action included in the request. In some embodiments, therequest to instantiate the offers interface may include the type ofaction to be performed and the contextual data in a URL requesting aoffers interface webpage from the mapped offers engine 12, 126, or 128,or these parameters may be included as arguments in a command launchingthe native application on the user computing device for interfacing withthe mapped offers engine 12, 126, or 128.

The mapping of a particular offers engine to the offers intent may occuras a result of a variety of different user interactions with the usercomputing device 124, depending upon the embodiment. For example, theuser computing device 124 may be a mobile computing device, and themapping may be performed as a result of the user installing a nativeapplication for interfacing with an offers engine on the user computingdevice 124. Part of the installation process may include setting thevalue of the offers engine mapping 132, for example, by changing aregistry value to indicate that the native application should belaunched (or the option of launching should be presented) upon a userselecting an offers intent within a website or other content (or uponthe user navigating to a website including the offers intent). Inanother example, the offers engine mapping 132 may be in memory of thebrowser 130, and the user may specify an offer engine 12, 126, or 128 tobe associated with the offers intent the first time the user selects theoffers intent within the browser, e.g., upon the user selecting anoffers intent, the browser may first determine whether an offers engineis mapped to the offers intent and, upon determining that no suchmapping exists, the browser may present the user with an interface bywhich the user may select an offers engine to be mapped to the offersintent.

To this end, in some embodiments, the offer-discovery system 122 mayinclude an intents directory server 134 hosting an API by which offerengines 12, 126, and 128 capable of handling a particular intent, suchas the offers intent, may be registered for identification to thebrowser 134 and presentation to the user during the process of selectingan offers engine to be mapped to the offers intent. The intentsdirectory server 134 may receive a query that specifies a type ofintent, such as the offers intent, and may respond to the query byreturning a list of services capable of handling the intent, such asidentifiers of offers engines 12, 126, and 128.

FIG. 5 is a flowchart of a process 136 by which offers intents aremapped to offers engines and by which user selection of offers intents(or navigating to a web page having such an intent) instantiates anoffers interface for communicating with the mapped offers engine. Theprocess 136, in some embodiments, may be performed by theabove-mentioned user computing device 124, for example by executinginstructions stored in a tangible, machine-readable, non-transitorymemory of the user computing device, which may store an operatingsystem, the browser, the offers engine mapping 132, and instructions forperforming the process 136.

In some embodiments, the process 136 includes navigating to a webpage.Navigating to the webpage may be performed by the user using the browseron the user computing device 124 described above with reference to FIG.4, for example. The webpage may be a merchant webpage, such as amerchant webpage having a checkout feature, or a webpage of one of theoffers engines 12, 126, or 128 that are also configured to interfacewith a corresponding native application.

Some embodiments of the process 136 further include determining whetherthe webpage contains an offers intent, as indicated by decision block140. Determining whether the webpage contains an offers intent mayinclude parsing HTML encoding portions (or all) of the webpage anddetecting the presence of an offers intent token, for example, abracketed tag including the string “intent” and various parameters, suchas an action to be performed, and contextual data, within the webpage.Detecting whether the webpage contains an offers intent may be performedby the browser 130 of the user computing device 124 described above withreference to FIG. 4 upon rendering the webpage or upon user selection ofan input associated with the intent. Upon determining that the webpagedoes not contain an offers intent, the process returns to step 138, andthe user navigates to other webpages, each of which the browser mayevaluate for an offers intent.

Upon determining that the webpage does contain an offers intent, in someembodiments, the process proceeds to determine whether an offers engineis then mapped to the offers intent, as indicated by block 142.Determining whether an offers engine has been mapped to the offersintent may be performed by the browser 130 of FIG. 4 as part ofrendering the webpage. In some embodiments, the browser may query theoffer service mapping 132 of user computing device 124 described abovewith reference to FIG. 4, which may be contained in browser memory or ina registry of the operating system of the user computing device 124.

Upon determining that an offers engine has not been mapped to the offersintent, the process 136, in some embodiments, proceeds to presentavailable offer engines for selection by the user, as indicated by block144. Alternatively, in some embodiments, upon determining that no offerengine is mapped to the offers intent, the process 136 may terminate,which is not to suggest that other steps described herein may not alsobe omitted in some embodiments. As noted above, presenting availableoffer engines for selection to the user may include querying, with thebrowser 130, an intents directory server 134, each of which is shown inFIG. 4. The user may select among the presented offer engines, and theselected offer engine may be mapped to the offers intent, as indicatedby block 146, for example in the offers engine mapping 132 of FIG. 4.

Next, the process 142 includes calling the mapped offers engine torequest offers potentially relevant to the webpage, as indicated byblock 148. Calling the mapped offers engine may include instantiating anoffers interface, such as a webpage from the offers engine or a nativeapplication for communicating with the offers engine, and the request toinstantiate the offers interface may include an action to be performedby the offers engine and data indicative of the context in which theoffers intent is presented (e.g., the identity of a merchant, the typeof item on a merchant webpage, or items in a shopping cart of themerchants webpage). Other embodiments may simply instantiate the offersinterface to communicate with the mapped offers engine without passingsuch parameters, e.g., some embodiments in which the offers interface isa native application launched in virtue of the user navigating to awebsite of the offers engine.

Next, the process 136, in some embodiments, includes presenting thepotentially relevant offers for selection by the user in theinstantiated offers interface, as indicated by block 150. Presenting thepotentially relevant offers for selection may be performed by the offersengine 12 transmitting a webpage to the user computing device 134, thewebpage being an offers interface, or by the user computing devicelaunching a native application that requests data about offers via anAPI server of the offers engine 12, 126, or 128 mapped to the offersintent.

Finally, the process 136, in some embodiments and use cases, includesentering a coupon code in an input for such codes in the webpage. Thisstep may be performed, for example, in some embodiments in which theoffers intent occurs within a merchant webpage, such as a merchantcheckout page, or the step may be performed by navigating to themerchant webpage within a webview launched by the native application.The coupon code may be entered manually by the user via the browser orthe offers interface may assist the user by loading the coupon code tomemory of the operating system, such as a clipboard memory or pastebinmemory, and pasting the stored coupon code into the input on themerchant webpage at the request of the user, e.g., by entering a pastecommand after selecting the appropriate input field of a merchantwebpage.

Further, in some embodiments, a drag-and-drop interaction may besupported, by which the coupon code may be displayed adjacent themerchant's webpage (e.g., in a header over an i-frame in which themerchant's checkout webpage is rendered), an event handler executing onthe user device detects a user selection of a coupon code (e.g.,touching or clicking), and code executing on the user device causes animage of the coupon code to be rendered under the area of the screenselected as the selection is translated by the user (e.g., with adragging or sliding gesture) to an input field in the merchant webpagefor receiving the coupon code, at which point the corresponding code isprogrammatically entered into the input field, e.g., by changing a valueattribute of a text input field to be the coupon code. In some cases,the coupon code may be automatically entered into such an input field bycode executing on the user device, e.g., JavaScript provided with theabove-described header may include an identifier of the input field onthe merchant's checkout webpage (e.g., an element id, class, or akeyword associated therewith), and the coupon code may be automaticallypopulated by searching the DOM for the corresponding identifier andchanging a value attribute of a responsive element to equal the code. Insome cases, other user information, e.g., shipping address and billinginformation, may be automatically completed in the merchant's webpageusing the same approach based on a user profile stored in the offersengine.

The process 136, in some embodiments, is expected to more tightlyintegrate the experience of shopping with the experience of discoveringoffers relative to other systems, as users can obtain their preferredoffers interface with relatively few user-driven steps, thereby loweringthe cognitive load placed on the user when using an offers engine.

In some embodiments, the offers intent may be expressed as a uniformresource identifier (URI) in a webpage or other content (including in anative application by a third party), and the offers intent URI (or aportion of the URI, such as a prefix) may be mapped in memory of theuser device to a native application that provides an offers interface.The mapping may be performed as part of the installation process of thenative application, and navigating the user device to the offers intentURI (or otherwise interacting with the URI) may cause the user device tolaunch the mapped native application. Further, in some embodiments, theURI may include arguments to be passed to the native application uponlaunch. The arguments may include an action to be performed, andparameters of that action, as explained below.

In one embodiment of a process for opening an offers intent, a URIidentifying an offers intent may be opened (or otherwise accessed) bythe user device. The URI may be accessed by a browser or some otherapplication on the user device, depending on the use case andembodiment. For instance, a user may request a webpage from the offersengine, and the offers engine may respond with a webpage havinginstructions that cause the browser to access the offers intent URI,e.g., JavaScript that attempts to open the URI. In some embodiments, theuser device may first detect whether an offers interface nativeapplication is mapped to the offers intent URI, and in response todetecting the mapping, open the native application. In another example,the browser may attempt to open the URI without first detecting if amapping is stored on the user device. In some cases, the above offersengine may respond to a request to a URL of the offers engine with a URIindicating an offers intent The URI may be provided with instructions toload the webpage in the event that the native application is notinstalled or is not mapped to the URI.

In some use cases, another native application, e.g., an applicationrelated to shopping, may open the offers intent URI. For example, thenative application or another native application may attempt to open (orotherwise access) the offers intent URI in response to a particulartrigger. In some embodiments, such a trigger may include the detectionof a user device at or near a particular location using, for example, ageo-location positioning method. In other embodiments, such a triggermay include the detection of, or a particular communication from, ashortwave or near field communication device. In another embodiment, anative application for scanning bar codes may attempt to open (orotherwise access) a URI for a deals intent in response to a successfulscan of a bar code, passing as parameters an identifier of a productfrom a scan of a bar code performed by the bar-code scanning nativeapplication and a requested action to search for related offers. Inanother example, a native application may attempt to open (or otherwiseaccess) the offers intent URI in response to the detection orrecognition of a product through analysis of a digital photo of theproduct. In another example, a native application for checking-in tomerchants' physical retail sites may open the offers intent URI upon auser checking in to a particular site, and the intent URI may include asa parameter an identifier of the merchant for searching for offers bythat merchant. In some cases, a user or administrator may instruct theuser device to open an offers intent URI, e.g., to configure the offersinterface native application or debug the application. In someembodiments, a merchant website may include a URI offers intent (orother form of offers intent), and a web browser rendering the webpagemay attempt to open the URI, thereby causing the offers intent to behandled by the designated service.

In some cases, the offers intent URI may be expressed in the followingformat: scheme://action/parameter-1/parameter-2/ etc. For instance, theoffers intent may be “retailmenot://view/topCoupons,” in which“retailmenot” is the scheme, “view” is the action, and the collection“topCoupons” is a parameter (which may be referred to as contextualdata). Other examples of schemes for intents offers include “coupons,”“popularstores,” “categories,” “store,” “coupon,” “search,” “debug,”“offers,” “deals,” “savings,” and the like. The scheme indicates thatthe intent is an offers intent and is what is mapped by the user deviceto the native application for viewing an offers interface, in thisembodiment. The “actions” field specifies actions to be performed by theoffers interface native application, and the actions may be performedbased on the parameters. Other examples include viewing featured offers,viewing recommended merchants, sharing a store, sharing an offer,designating an offer as a favorite, submitting an offer, etc.

Other examples of actions include “delete,” “update,” “favorite,”“share,” “redeem,” “use,” “save,” “synch,” and “apply,” each of whichmay be followed by parameters that indicate the item upon which theaction should be performed, e.g., a “coupon,” “mobile wallet” or“offer,” and a parameter that identifies an instance of the item, suchas a coupon identifier. In other examples, the action may be “favorite,”followed by parameters that identify a type of item to be added as afavorite and an identifier of a specific instance of the type of item.In another example, the action may be “view,” and a parameter mayspecify a collection to view, such as top coupons or popular stores. Orthe action may be “search,” and the parameters may identify a field tosearch (e.g., stores or categories) and search criteria (e.g., searchtext or category tags). The action may also specify a mode in which toopen the native application, e.g., a “debug” action may open the nativeapplication in a debug mode. Further, calling the offers intent URIwithout specifying an action or parameters may cause the nativeapplication to open in a default mode.

For instance, a URI of “offers://share/coupon_no_1234” may cause anative application on the client device to be launched and toautomatically transmit a request to the offers engine to designate thecoupon having the identifier “coupon_no_1234” as being shared in a userprofile of the corresponding user. Or a URI of“offers://view/recommended_merchants” may cause the native applicationto open, request a list of recommended merchants from the offers engine,and display those merchants to the user in an initial state. In anotherexample, a URI of “offers://view/featured_offers” may cause a similarsequence to retrieve and display offers designated as “featured” by anadministrator of the offers engine. In some embodiments, a URI of“offers://favorite/coupon_no_1234” may cause the native application todesignate the corresponding coupon as being a favorite of the user in auser profile of the offers engine. In another example, a URI of“offers://submit/offer” may cause an offer to be added to the offersstored and provided by the offers engine, e.g., this URI may cause thenative application to launch with a form display by which attributes ofan offer are entered and submitted by a user, or a sequence ofadditional parameters may designate such attributes.

Thus, in this embodiment, the mobile user device may respond to anattempt to open the URI (by a browser or other application) by launchingthe native application for interfacing with the offers engine.

It should be understood that the description and the drawings are notintended to limit the invention to the particular form disclosed, but tothe contrary, the intention is to cover all modifications, equivalents,and alternatives falling within the spirit and scope of the presentinvention as defined by the appended claims. Further modifications andalternative embodiments of various aspects of the invention will beapparent to those skilled in the art in view of this description.Accordingly, this description and the drawings are to be construed asillustrative only and are for the purpose of teaching those skilled inthe art the general manner of carrying out the invention. It is to beunderstood that the forms of the invention shown and described hereinare to be taken as examples of embodiments. Elements and materials maybe substituted for those illustrated and described herein, parts andprocesses may be reversed or omitted, and certain features of theinvention may be utilized independently, all as would be apparent to oneskilled in the art after having the benefit of this description of theinvention. Changes may be made in the elements described herein withoutdeparting from the spirit and scope of the invention as described in thefollowing claims. Headings used herein are for organizational purposesonly and are not meant to be used to limit the scope of the description.

As used throughout this application, the word “may” is used in apermissive sense (i.e., meaning having the potential to), rather thanthe mandatory sense (i.e., meaning must). The words “include,”“including,” and “includes,” and the like mean including, but notlimited to. As used throughout this application, the singular forms “a,”“an,” and “the” include plural referents unless the content explicitlyindicates otherwise. Thus, for example, reference to “an element” or “aelement” includes a combination of two or more elements, notwithstandinguse of other terms and phrases for one or more elements, such as “one ormore.” The term “or” is, unless indicated otherwise, non-exclusive,i.e., encompassing both “and” and “or.” Terms relating to causalrelationships, e.g., “in response to,” “upon,” “when,” and the like,encompass causal relationships having both causes that are a necessarycausal condition and causes that are a sufficient causal condition,e.g., “state X occurs upon condition Y obtaining” is generic to “Xoccurs solely upon Y” and “X occurs upon Y and Z.” Similarly, unlessotherwise indicated, statements that one value or action is “based on”another condition or value encompass both instances in which thecondition or value is the sole factor and instances in which thecondition or value is one factor among a plurality of factors. Unlessspecifically stated otherwise, as apparent from the discussion, it isappreciated that throughout this specification discussions utilizingterms such as “processing”, “computing”, “calculating”, “determining” orthe like refer to actions or processes of a specific apparatus, such asa special purpose computer or a similar special purpose electronicprocessing/computing device. In the context of this specification, aspecial purpose computer or a similar special purpose electronicprocessing or computing device is capable of manipulating ortransforming signals, for instance signals represented as physicalelectronic, optical, or magnetic quantities within memories, registers,or other information storage devices, transmission devices, or displaydevices of the special purpose computer or similar special purposeprocessing or computing device.

What is claimed is:
 1. A tangible, non-transitory, machine-readablemedium storing instructions that, when executed by data processingapparatus, cause the data processing apparatus to perform operationscomprising: installing an offers application on a user device, whereininstalling the offers application includes registering the offersapplication in memory of the user device as a designated application tohandle offers intents, the offers intents being asynchronous calls fromanother application to request services related to offers; and handling,with a processor, an offers intent upon another application accessingthe offers intent, wherein handling the offers intent comprises:launching the offers application; receiving, with the offersapplication, an action related to offers and specified in the handledoffers intent; receiving, with the offers application, a parameterrelated to offers and specified in the handled offers intent; andperforming, with the offers application, the action based on theparameter.
 2. The medium of claim 1, wherein the action is a request toview offers, the parameter identifies an offer, and performing theaction comprises displaying the offer with a native offers application.3. The medium of claim 2, wherein performing the action comprisesrequesting the offer from an offers engine over a network.
 4. The mediumof claim 2, wherein the parameter identifies an offer by specifying amerchant and performing the action comprises requesting offers by themerchant.
 5. The medium of claim 4, wherein the offers intent iscontained in a web page of the merchant, and the offers application islaunched by a web browser rendering the web page and accessing a uniformresource identifier in the web page containing the offers intent.
 6. Themedium of claim 2, wherein the parameter specifies a collection ofoffers being ranked above a threshold rank.
 7. The medium of claim 2,wherein the parameter specifies offers in a category of coupons.
 8. Themedium of claim 2, wherein the operations comprise: handling a differentoffers intent upon a third application accessing the different offersintent.
 9. The medium of claim 1, wherein the other application isoperative to identify a merchant or a product by scanning amachine-readable product identifier with an optical sensor of the userdevice and request, using the offers intent, offers related to theidentified merchant or product.
 10. The medium of claim 1, wherein theother application is a web browser rendering a web page, and wherein theweb browser launches the offers application by accessing a uniformresource identifier contained in the web page.
 11. The medium of claim1, wherein the other application is another native application, theother native application being a non-browser application, and a commandin the other native application is a request for the offers intent.